Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@frontend/app/view/processviewer/processviewer.tsx`:
- Around line 239-241: The keyDownHandler currently only checks for "Cmd:f" so
the UI hint for non-macOS (Alt-F) never triggers on Windows/Linux; update the
handler(s) (keyDownHandler and the similar handler around the second occurrence)
to check the appropriate modifier(s) for non-macOS — e.g., detect platform or
test both "Cmd:f" and "Alt:f" (or "Ctrl:f" if your keyutil expects Ctrl on
Windows) and call this.openSearch() when either variant matches, ensuring both
shortcut hints and behavior stay in sync.
- Around line 224-226: The virtualization height is being computed from the
unfiltered totalcount causing the scroller to remain sized to the full dataset
and allowing a deep scrollTop to request empty pages; in setTextSearch (which
writes textSearchAtom and calls triggerRefresh) update the code that computes
totalHeight/virtualization size to use filteredcount instead of totalcount and
also reset the scroller position (clear scrollTop / set to 0) when the search
text changes so the view jumps to the top of the newly filtered results; locate
uses of totalHeight, totalcount and any scrollTop manipulation in the
virtualized list rendering and update them accordingly (also apply same change
around the other affected block referenced at lines ~769-797).
- Around line 202-209: triggerRefresh currently returns early when paused
(this.pausedAtom) which prevents user-driven one-shot updates
(scrollTop/containerHeight/textSearch) from fetching the correct page; change
the logic in triggerRefresh (and the similar blocks around the other occurrences
noted) so that pausing only disables the recurring timer
(cancelPoll/startPolling) but does not prevent immediate fetches for user
actions—i.e., if the call was triggered by a user-driven event
(scroll/search/resize) or if parameters affecting server pagination changed,
still call the routine that performs a single fetch/update (the same code
startPolling would use for one-shot fetches or the page-fetch method used in the
polling loop) while keeping cancelPoll cleared and the periodic poll disabled
when paused. Ensure references: triggerRefresh, startPolling, cancelPoll,
pausedAtom, and the fetch/update routine are updated consistently in the other
blocks around the noted occurrences.

In `@frontend/preview/previews/processviewer.preview.tsx`:
- Around line 40-67: makeMockProcessListResponse currently ignores
data.textsearch so previews never exercise filtering and filteredcount is wrong;
update makeMockProcessListResponse to apply the text search (data.textsearch) to
MockProcesses first (produce a filtered list), keep totalcount as the original
MockProcesses.length, then sort and slice the filtered list (use the same sort
logic and variables like sortBy, sortDesc, start, limit) and set filteredcount
to the filtered list length before paging; reference
makeMockProcessListResponse, MockProcesses, data.textsearch, filteredcount and
totalcount when making the change.
- Around line 82-84: The preview currently overrides only
RemoteProcessListCommand via useRpcOverride and thus ignores kill/stop/resume
actions; add a corresponding useRpcOverride for RemoteProcessSignalCommand (or
update the existing override set) to either simulate the signal effects on the
mock process state (e.g., update the mock returned by
makeMockProcessListResponse) or explicitly reject the RPC so the UI doesn't
report a spurious success; reference the existing useRpcOverride call and
makeMockProcessListResponse to locate where to add the
RemoteProcessSignalCommand handler and ensure it returns a realistic mocked
response or a rejected Promise.

In `@pkg/util/procinfo/procinfo_darwin.go`:
- Around line 84-89: The ProcInfo construction uses k.Proc.P_comm which is
truncated at 16 chars; update the logic that sets ProcInfo.Command (in
pkg/util/procinfo/procinfo_darwin.go) to attempt retrieving a full command name
via libproc (e.g. proc_name or proc_pidpath) using the process PID
(k.Proc.P_pid) through the existing purego binding mechanism, and only fall back
to unix.ByteSliceToString(k.Proc.P_comm[:]) if those libproc calls fail or
return empty; ensure the new code populates ProcInfo.Command with the full
path/name when available and preserves the existing behavior on error.

In `@pkg/util/procinfo/procinfo_linux.go`:
- Around line 15-17: Replace the hard-coded const userHz = 100.0 with a runtime
lookup of CLK_TCK and use that value where CPU ticks are converted (references:
userHz and the code that divides utime/stime at lines ~110-111); implement a
helper like getUserHz() that calls unix.Sysconf(unix._SC_CLK_TCK) (from
golang.org/x/sys/unix), converts the returned tick count to float64, caches it
for subsequent calls, and falls back to 100.0 only if Sysconf returns an error
or non-positive value; update usages to call this helper (or read the cached
value) instead of the constant.
- Around line 71-73: The current parsing sets ProcInfo.Command from the
truncated comm value parsed as comm := s[lp+1 : rp]; instead, read
/proc/[pid]/cmdline for the full command (split NUL bytes and join with spaces)
and set ProcInfo.Command from that; if /proc/[pid]/cmdline is empty or
unavailable, fall back to the existing comm value (trim parentheses) as a
secondary source. Update the parsing logic in procinfo_linux.go (the code that
produces pidStr, comm and rest) to attempt reading cmdline first, handle
NUL-separated args, and only use comm when cmdline yields no usable command.
Ensure ProcInfo.Command uses the cmdline output so long process names aren’t
silently truncated.

In `@pkg/wshrpc/wshremote/processviewer.go`:
- Around line 427-430: The current logic resets limit to 50 whenever data.Limit
is <=0 or >500; instead keep the default for non-positive inputs but clamp
oversized inputs to 500: validate data.Limit into the local variable limit so
that if data.Limit <= 0 you set limit to 50, otherwise if data.Limit > 500 set
limit to 500, else set limit = data.Limit; update the code around the variable
limit (the block using data.Limit and limit) to implement this three-way check.

---

Nitpick comments:
In `@pkg/util/unixutil/unixutil_unix.go`:
- Around line 83-94: The SendSignalByName function currently treats
os.FindProcess errors as "process not found", but on Unix FindProcess rarely
fails (only for pid <= 0) and the real errors come from p.Signal; update
SendSignalByName to validate pid > 0 up front (returning a clear error for
invalid pid), call ParseSignal as before, call os.FindProcess without assuming
non-existence, and rely on p.Signal(sig) to surface real runtime errors (or wrap
the p.Signal error with context). Reference: SendSignalByName, ParseSignal,
os.FindProcess, p.Signal.

In `@pkg/wshrpc/wshremote/processviewer.go`:
- Around line 184-201: The current loop spawns one goroutine per process which
can create thousands of concurrent procinfo.GetProcInfo calls; replace it with a
bounded worker pool (size based on runtime.GOMAXPROCS(0) or runtime.NumCPU) that
consumes jobs from a channel of tasks containing (index i, p.Pid) and writes
results back into rawInfos[index] as pidInfo; ensure workers use the same panic
handling (panichandler.PanicHandler("collectSnapshot:GetProcInfo", ...)), use a
WaitGroup to wait for all jobs to finish, propagate nil on error from
procinfo.GetProcInfo, and close the jobs channel to signal workers to exit so
sampling cost stays predictable.